Security hole leaves IBM Domino server wide open - Part One
Background
IBM has lately been playing a "catch up" game in regards to security with IBM Domino. With Poodle, Heartbleed etc. IBM has been busy with fixes for IBM Domino, but it is mess for Administrators to fix issues and only version 9 of IBM Domino is being fully fixed.
This means that many have been using a Reverse Proxy, like Nginx, HAProxy or the included IBM HTTP Web Server in front of the IBM Domino server as a fix.
There are lots of good guides how to setup a Reverse Proxy in front of IBM Domino.
Jesse Gallagher has written several good guides like this guide on how to use Nginx with IBM Domino.
IBM has several guides how to install the IBM HTTP Server with Domino
All the guides refer to the setting in the Notes.ini you must set on the IBM Domino server
HTTPEnableConnectorHeaders=1
The setting comes from "way back when" (R6) IBM decided to ditch IBM Domino for IBM Websphere.
IBM wanted to customers to buy IBM Webphere servers instead of Lotus Domino servers, but customers had of course still Domino servers around for years so IBM decided that the users should be able to connect to the Domino server via the Webphere servers.
Like sort of a Reverse Proxy.
IBM then defined several special fields to be sent in the HTTP headers from the Websphere server to the Domino server to make them work together.
| $WSAT: The Auth Type that is being used to make this request. $WSCC: The Client Certificate used for this request. If the value is not base64 encoded for us by the Web server, then the plug-in will base64 encode it before sending it across to the application server. Restriction: If you enable this, it is assumed you know what you’re doing, and how to protect direct access to the port at which the embedded http is listening. Note: If you set the LogLevel to TRACE in the plugin XML config file, it is possible to see what headers are actually added for a given request. Appendix C. Domino 6 HTTP plug-in hints and tips 659 $WSCS: The cipher suite that the Web server negotiated with the client. This is not necessarily the cipher suite that the plug-in will use to send the request across to the application server. $WSIS: This header will be set to either True or False depending on whether or not the request is secure (came in over SSL/TLS). $WSSC: The scheme being used for the request. This header will normally be set to either http or https. $WSPR: The HTTP protocol level being used for this request. The plug-in currently has support for up to HTTP/1.1 requests. $WSRA: The remote IP address of the machine the client is running on. $WSRH: The remote host name of the machine the client is running on. If the hostname can't be resolved, this header should be set to the IP address. $WSRU: The remote user specified for the given request. $WSSN: The server name used for this request. This should be the value that was specified in the HOST header of the incoming request. $WSSP: The server port that the request was received on. This will be the port value that is used in route determination. $WSSI: The SSL Session ID being used for this request. If the value is not base64 encoded for us by the Web server, the plug-in will base64 encode it before sending it across to the application server. |
In my next blogentry I will tell you why this was a horrible idea and it leaves Domino wide open.
I can tell you already that you should go and set HTTPEnableConnectorHeaders=0 on all your servers now.
Lastly ....I will in another blogentry show that you actually don't need to have this setting enabled in Domino to have a fully functional Reverse Proxy server in front of a IBM Domino server.
Posted on 09/18/2015 05:45:31 PM CEDT
Show Comments(17)
Create Comment